Method and system for module chaining control in a modular software architecture

ABSTRACT

The method to check module chaining in a modular software architecture located in an electronic unit with microprocessor comprising, apart from the microprocessor, a memory space, uses an identification, secured by the hardware, of the calling module. The invention also concerns an electronic unit with microprocessor designed to implement the above method.

BACKGROUND OF THE INVENTION

This invention concerns the module chaining control in a modularsoftware architecture located in an electronic unit with microprocessor.The invention is for example applicable to, but not limited to,electronic smartcards.

1. Field of the Invention

A modular software architecture comprises several modules definedaccording to the tasks they have to execute. While executing its tasks,each module can call other modules. These modules can be grouped inlayers, and in this type of model, the modules of a higher layergenerally call the modules of the layer immediately below to processsome of the tasks they must perform. In practice, for example, in asoftware architecture for smartcard, all modules can be grouped in threemain layers called the “core” layer interfacing directly with thehardware (in particular the processor, memories and input/outputinterfaces), the “system” layer concerning the operating system (OS) andthe “application” layer concerning the various software applications.

To each module there corresponds a particular, well identified memoryarea grouping memory sections to store the corresponding program (nonvolatile memory), memory sections to store the data associated with thismodule (non volatile memory) and memory sections exclusively used bythis program for its execution (volatile memory). A unique identifierdesignates both a module and the corresponding memory area.

When a module calls explicitly another module by an inter-module call,execution of the calling module program is followed by execution of thecalled module program. Any other form of chaining the execution ofprograms belonging to different modules is prohibited by hardwaremechanisms.

It may be necessary, especially for security purposes, to only allowcertain clearly specified modules to call a given module. For example, acertain module in the core layer accessing the data memory can only becalled by a module in the system layer and never by a module in theapplication layer, or a module in the application layer can only becalled by a particular module in the system layer and never by anothermodule in the same layer. Equally, according to another example, amodule in the application layer, since it acts as card administrator,can request services that the other modules in the same layer are notallowed to obtain.

In the context of this type of limitation, since a calling module cancall any other module, it is the called module or an intermediate systembetween the calling module and the called module which applies a checkof program chaining. Consequently, the called module or the intermediatesystem must be able to reliably and unambiguously identify the callingmodule. In addition, the behaviour of the called module can bedetermined and configured according to the identity of the callingmodule obtained.

The identification of the calling module is secured if:

-   -   firstly, it does not rely on the “good faith” of the calling        module (i.e. the information concerning the identification of        the calling module communicated by said calling module is        checked); and    -   secondly, the identification mechanism is protected against        modification attempts carried out by malicious software likely        to produce incorrect identification of the calling module.

2. Description of the Related Art

Software solutions to identify a calling module have already beenproposed, in which a variable is used in the program to identify theactive module. However, this purely software approach has certaindisadvantages. Firstly, it is easily compromised, due to its purelysoftware nature, by an impostor seeking to illegally benefit from theunauthorised resources either by modifying the identification variablein memory or by changing the program used to manage this variable.Secondly, with organisation in layers, although the operating system caneasily identify applications since applications are run by said system,this is not the case for other identifications such as identification ofmodules in the operating system itself by the core: in this case, infact, the information is not available.

The most common solution is to use cryptography to guarantee theidentity declared by the calling module, i.e. use an authenticationmechanism. However, in this case significant resources are required: akey known by the potentially called modules is required by eachpotentially calling module, as well as a cryptographic calculation foreach call.

The invention concerns a method for secured identification of a callingmodule in a modular architecture which avoids the disadvantagesdescribed whilst remaining relatively simple.

SUMMARY OF THE INVENTION

The invention therefore proposes a method to check module chaining in amodular software architecture located in an electronic unit withmicroprocessor comprising, apart from the microprocessor, a memoryspace, characterised in that the check is carried out using anidentification, secured by the hardware, of the calling module.

The invention concerns a method for secured identification of a callingmodule in a modular software architecture located in an electronic unitwith microprocessor comprising, apart from the microprocessor, a memoryspace, characterised in that it consists, during an inter-module call,in saving information used to identify the calling module in protectedmemory before branching the execution to a precise point in the programof the called module and using the saved information to identify thecalling module.

An inter-module call therefore triggers the execution of a routine whichwrites in memory information sufficient to identify the calling modulethen manages the jump to an address indexed by a parameter of the call.An advantage as regards the security is that any other type of jump fromone module to another module is prohibited by the hardware.

The calls for a given module are therefore channelled into one or morespecified entry points in order to systematically check the identity ofthe calling module and restrict access to authorised modules only,according to the previously stored check information.

The invention also concerns an electronic unit with microprocessorcomprising at least a microprocessor and a memory space, the unitcomprising hardware and software means designed to implement theidentification method according to the invention as defined above in allits variants and/or execution modes. In particular, the invention ismost suitable for use in microcontrollers located in smartcards.

The invention concerns an integrated circuit card comprising anelectronic unit with microprocessor designed to implement the calleridentification method according to the invention.

The invention concerns a computer program including program codeinstructions for the execution of steps of said method when said programis executed in a computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

Other purposes, features and advantages of the invention will appear onreading the description which follows of the implementation of themethod according to the invention and of a mode of realisation of anelectronic unit with microprocessor designed for this implementation,given as a non-limiting example, and referring to the attached drawingsin which:

FIG. 1 is a diagrammatic representation of a non-limiting mode ofrealisation of an electronic unit with microprocessor designed to usethe secured identification method according to the invention;

FIG. 2 is a diagrammatic representation of the central processing unitof the microprocessor shown on FIG. 1;

FIGS. 3 and 3 bis are diagrammatic representations of the modularsoftware architecture of the electronic unit shown on FIG. 1;

FIG. 4 is a diagrammatic representation of a first form of realisationof the steps in the method according to this invention;

FIG. 5 is a flowchart representing the various steps of the securedidentification method according to this invention;

FIG. 6 is a diagrammatic representation of a second form of realisationof the steps in the secured identification method according to thisinvention;

FIG. 7 represents an optional step in the secured identification methodaccording to this invention.

DESCRIPTION OF THE INVENTION

This invention belongs to the field of securing electronic unitscomprising at least a microprocessor, a non volatile memory of type ROM,EEPROM, Flash, FeRam storing at least a program to be executed, avolatile memory of type RAM and input/output means to communicate withthe exterior. This type of unit is generally manufactured as amonolithic integrated electronic circuit, or chip, which once physicallyprotected by any known means can be assembled on a portable object suchas, for example, a smartcard, integrated circuit card or similar for usein various fields, especially the bank and/or electronic payment cards,mobile radio telephony, pay television, health and transport.

The monolithic electronic unit 10 with microprocessor illustrated onFIG. 1 and described as a non-limiting example generally comprises amicroprocessor CPU 11 with two-way connection via an internal bus 12 torandom access memory RAM 14, read only memory ROM 16, memory EEPROM 18or similar and an input/output interface I/O 20. The module 10 maycomprise additional components not shown, connected to the internal bus,such as for example a reversible counter or a pseudo-random numbergenerator.

Traditionally, the central processing unit of the microprocessor CPU 11illustrated on FIG. 2 comprises an arithmetic and logic unit UAL 22, aninstruction decoding unit DECOD 24 and a set of working registers (suchas for example in the CISC-Complex Instruction Set Computer-architecturein particular an accumulator A 26, at least a temporary storage registerX and/or Y 28), a program counter CO 30 indicating the address of thenext instruction to be executed, a stack pointer PP 32 indicating thestorage address of the top of the stack of execution and a statusregister RE 34 providing various types of information on theinstantaneous operational status of certain registers or other parts ofthe microprocessor CPU 11.

The memory space of the electronic unit 10 consists of the memory RAM14, the memory ROM 16 and the memory EEPROM 18. This space storesvarious types of software organised as software modules according to a“modular” architecture and often represented as software layers (seeFIG. 3). From the hardware layer consisting of the electronic unit 10,we can identify the “core” software layer (“N” on FIG. 3) 36 concerningamongst other things the microprocessor reset, input/output management,interrupt management, the operating system layer OS 38 concerning inparticular the system configuration, organisation of system operationregarding applications, organisation of memory space and addressing,management of peripherals, and the “application” layer 40 with residentapplications 41, 42 for example a program interpreter written in SUNMICROSYSTEMS JAVA language and “user” applications 43, 44 and 45corresponding to precise features (example: bank card, health card,identity card).

According to the example illustrated on FIG. 3 bis, the “application”layer 40 itself contains the services (S) shared by several applicationsand the “operating system” layer 38 is divided into modules (M1 to M6)corresponding to the major functions of this layer.

Regarding the memory addressing, the non volatile memory space isdivided into memory pages, for example of 128 bytes, with partitionsbetween the various areas where the various modules will be stored.Traditionally, the first non volatile memory area available which is thelowest addressing area is used to store an address table 46 (FIG. 6)giving the entry points of the interrupt and reset management routinescommonly called the “interrupt and reset vector table”. Each applicationmodule or user module has an addressing field storing the correspondingprograms of the application as well as the fixed or variable dataavailable to the application. The “user” applications 43, 44 and 45 cantherefore be stored in the EEPROM memory. These applications which sharelayer 40 often include confidential data specific to them and which mustbe protected, for example payment codes for the bank cards, encryptionkeys for electronic signature payment cards or for pay television cards,personal information for the health cards. The integrity of eachapplication, and more generally of each module including the OS and thecore, must be protected by denying any unauthorised memory access incase of inter-module call. A patent application filed the same day asthis application by the same applicant entitled “access control methodand device in an embedded system” concerns this memory access controlduring an inter-module call. This access control starts with securedidentification of the calling module.

An inter-module call is a call from a module known as the calling moduleto another module known as the called module.

Generally, an inter-module call is made by an instruction or executableprocedure used to execute a resident program in a memory area differentfrom the memory area of the calling module.

With modular architecture, the inter-module calls are immediatelyrecognised as such being microprocessor instructions.

Once the call is recognised as being an inter-module call, informationused for identification, hereafter referred to as the identificationinformation, is automatically saved (step 3 on FIG. 5). The inter-modulecall triggers said save. The calling module identification informationis saved in protected memory before branching execution to a precisepoint in the program of the called module. The memory is protected asfollows: The identification information is saved in one or more memoryfields accessible in read only mode by programs such as for example thecalled module, the writes only being carried out by a save routine 47.

The information saved in the protected memory is used to identify thecalling module. An inter-module call therefore triggers the execution ofa routine which writes in memory information sufficient to identify thecalling module then manages the jump to an address indexed by aparameter of the call. An advantage as regards the security is that anyother type of jump from one module to another module is prohibited bythe hardware.

The calls for a given module are therefore channelled into one or morespecified entry points in order to systematically identify (step 5) thecalling module and check the program chaining (step 7) according topreviously stored check information.

According to several variants of the identification information saveoperation (step 3), the content of one or more registers of the centralprocessing unit in the microprocessor 11 is stored. At least thecontents of the program counter CO 30 and/or CO′ 30′ or of the statuscounter RE 34 are stored.

Execution of the routine 47 saving the identification information, whichis triggered by the inter-module call, must not disturb said informationand in particular the content of the program counter or of the statusregister.

Consequently, according to a first form of realisation of the methodillustrated on FIG. 4, the save routine is executed in a mode differentfrom that of the other modules: the save routine 47 is executed inprivileged mode (or system mode) (“priv mode” on FIG. 4), using adifferent program counter 30′. The save routine 47 saves theidentification information by carrying out execution using the programcounter 30′. The memory used by the routine 47 to save theidentification information is protected since said routine works inprivileged mode i.e. in a mode where the code and the data cannot beaccessed by programs which do not execute in privileged mode, such asthe user programs (for example the calling module). The routine 47 thenidentifies the calling module and checks the program chaining. Note thatthe called module can carry out the identification and program chainingcheck steps itself. Said form of realisation is used to save theidentification information of application modules executing in ordinary(or user) mode, and therefore to identify them. However, it cannot beused to identify modules which are executed in privileged mode.

Consequently, according to a second preferred form of realisation of theinvention illustrated on FIG. 6, to identify all types of softwaremodule, the execution of the routine should be handled by the hardware,in particular the inter-module call instruction should belong to thepreprogrammed microcode instruction set of the microprocessor. The wholechecking method is performed automatically and secured by hardwaremeans.

According to a mode of realisation of the method according to theinvention, the inter-module call instruction is based on a “TRAP” typeinterrupt instruction or a similar “capture” type instruction belongingto the preprogrammed microcode instruction set of the microprocessor.During an inter-module call, the TRAP instruction is run automatically.The TRAP or similar instruction saves the identification information ofstep 3 in a protected memory. As indicated above, the memory isprotected since it can only be accessed in read mode, the writes onlybeing authorised to the microcode of the save routine 47 (TRAP).

Advantageously, the TRAP instruction or the similar instruction triggersthe execution of a program interrupt management routine 48 known as theidentification and program chaining check routine 48 specified in thestored predefined vector table 46 indicating the address of the entrypoint of said routine 48.

As shown on FIG. 6, the TRAP instruction or any similar instructionincludes one or more call parameters (in the example of FIG. 6, twoparameters x,y, TRAP(x,y)) which specifies the type of inter-modulecall, each call type triggering the execution of differentidentification and program chaining check routines 48 whose entry pointsare indexed in the vector table 46. The parameters x,y of the TRAPinstruction determine respectively the identification and programchaining check routine 48 and the called module 49 to which said routinebranches or an entry point in said called module 49 when there areseveral of them.

In the example illustrated on FIG. 6, the first parameter x indicates anentry in the vector table 46. TRAP(1,A1) points to entry 1 of table 46:entry 1 specifies the address of the identification routine “Routine 1”i.e. Adr1. Similarly, TRAP(2, E1) and TRAP(3, E2) point respectively toentries 2 and 3 which specify respectively the addresses of “Routine 2”and “Routine 3”. The second parameter is a variable used by theidentification routine 48 to determine the called module or a particularentry point in said called module; at the end of routine 48 “Routine1”,the called module in which the program continues varies depending on thevalue of the second parameter. Consequently, in routine “Routine1”, ifthe value of parameter y is A1, which is the case on FIG. 6, routine“Routine 1” branches to module 49 called A1 in which the programexecution continues. If the value of parameter y is A2, routine “Routine1” branches to module 49 called A2. In routine 48 “Routine2”, if thevalue of parameter y is E1, routine “Routine 2” branches to entry pointE1 of module 49 called A3. If the value of parameter y is E2, routine“Routine 2” branches to entry point E2 of the same module A3. In routine48 “Routine3”, if the value of parameter y is E3, routine 48 “Routine 3”branches to entry point E3 of module 49 called A5. If the value ofparameter y is E2, routine “Routine 3” branches to entry point E2 of thesame module A5. If the value of parameter y is E1, routine “Routine 3”branches to entry point E1 of another module called A4.

If the called module is not explicitly identified (for example a modulebelonging to the core or to the OS), the TRAP instruction points in theinterrupt vector table 46 to a default entry point.

Note that the identification and program chaining check routine 48 canbelong to the called module. The TRAP instruction points in the vectortable 46 to a unique entry point, specific to a called module: saidentry specifies the address of an identification and program chainingcheck routine specific to the called module.

The calling module identification and program chaining check steps 5 and7 are carried out according to the form of realisation described aboveeither by the save routine 47, by the identification and programchaining check routine 48, or by the called module itself.

The method according to the invention consists in step 5 of identifyingthe calling module. Module identification is carried out by a uniqueidentifier which characterises firstly the tasks which can be executedby this module and secondly the memory area corresponding to thismodule. Management of the association between addresses belonging to amemory area and identifier is either centralised in a table, known asthe identifier table, or decentralised as an identification attributeincluding this identifier attached to each address or group ofcontiguous addresses called a memory page, the identification attributeshowing the identification of the module to which the address or thememory page belongs.

According to one form of realisation of step 3 of the method accordingto the invention, the information saved used to identify the callingmodule in step 5 (identification information) consists in the content ofat least one of the following registers associated with themicroprocessor: the program counter CO, the status register RE, saididentification information save operation consisting in storage of thecontent of at least one of said registers.

According to a first realisation variant of identification step 5,identification of the calling module is carried out using the content ofthe program counter 30 which indicates the address of the nextinstruction in the program currently being executed in the callingmodule. In case of centralised management, with the identifier tableindicating the addressing areas of the various applications, usingcomparison operations it is easy to find the addressing area of thecalling module and identify the corresponding application. In case ofdecentralised management, identification is carried out by reading theidentification attribute attached to the address saved.

Note that, in the form of realisation illustrated on FIG. 6, the contentof the program counter 30 is stored in a memory field accessible by thecalled module or the routine 48 in read only mode (write is onlyauthorised for the TRAP instruction microcode, i.e. the save routine47).

According to a second realisation variant of step 5, the calling moduleis identified by an identifier contained in the status register andsaved when the identification information is saved. In practice, thebits in the status register not used by the system are used to store thecalling module identifier before saving the content of the statusregister.

Note that, in the form of realisation illustrated on FIG. 6, the contentof the status register 34 (indicating the calling module identifierdirectly) is stored in a memory field accessible by the identificationand program chaining check routine 48 and by the called module in readonly mode (write is only authorised for the TRAP instruction microcode,i.e. the save routine 47).

As shown on FIG. 5, a second step consists in updating the statusregister before any identification. Step 2 is represented in dottedlines since it only belongs to the method according to the second formof realisation. The update of the status register is activated by theinter-module call. The identifier stored in the status register RE isautomatically updated from an address in the calling module program,either by comparison in the identifier table in case of centralisedmanagement, or by reading the identification attribute of the pagecontaining the inter-module call instruction in case of decentralisedmanagement of the association. An advantage as regards the security isthat this address can be that stored in the program counter CO at thetime of the inter-module call.

Consequently, the second realisation variant allowing the hardware toupdate the identifier avoids code duplication and the possibility ofprogramming error and simplifies the task of the called module whichaccesses the calling module identifier directly.

During a seventh step, the method according to the invention checkswhether the calling module identified in step 5 is authorised to accessthe called module. Depending on the form of realisation, the programchaining check is carried out:

-   -   by the save routine 47;    -   by the identification and program chaining check routine 48;    -   or by the called module.

Routine 47 or 48 or possibly the called module looks in a programchaining authorisation table amongst the various modules whether thecalling module is authorised to call the called module. The programchaining authorisation table is predefined and stored in read only,except for a particular module with administration rights and which haswrite access to said table.

If program chaining is authorised, routines 47 and 48 branch to aspecified point of a given called module from which execution continueswhen said routine 47 or 48 is finished. If a check is carried out by thecalled module itself, execution of the module continues when said checkis finished. In the event of failure, the program of the called moduleis stopped and a warning message is returned to the calling module.

Optionally (as indicated by the dotted lines on FIG. 5) butadvantageously for security reasons, in a fourth step the methodaccording to the invention carries out a first consistency check. Theidentification information is saved both for the calling module and thecalled module. As shown on FIG. 7, a calling module B calls a calledmodule C, the calling module B having been called by a calling module A.Module B has two items of identification information, that of the start(at the time of the inter-module call A/B, when execution of module Bstarts) and that of the end (at the time of the inter-module call B/C,when execution of module B ends) of its continuous execution sequence.The consistency check is carried out at the time of the inter-modulecall (in this case the call B/C): the identification informationregarding the start and end of module B, and more especially theidentifier of module B at the start and end of sequence, are compared.Any difference in identifier indicates inconsistency which could be dueto external attack: as a result, the current program is stoppedautomatically and a warning message is output.

Optionally (as indicated by the dotted lines on FIG. 5) and as a finalcheck, in a sixth step a second consistency check is carried out. Theoperation consists in comparing the presumed identification of thecalling module obtained using software (see above for exampleidentification variable) and the identification of this module obtainedby reading the saved identification information. Any discrepancy couldbe considered as a sign of external hardware and/or software attack and,as a result, program execution is stopped and/or an error messageoutput.

The method used to identify the calling module which has just beendescribed as a non-limiting example in its two main variants (FIG. 4 andFIG. 6) can be modified to suit the requirements of the modular softwarearchitecture designer as long as the identification information is savedby a privileged instruction, preferably microcoded in a memory, properlyprotected against external attacks. In particular, without leaving thescope of the invention, it is possible to limit the save of theidentification information to that of a single register, the programcounter or the status register, depending on the location of theinformation concerning the calling module to be retrieved for theremainder of the processing.

The invention also concerns the electronic units 10 with microprocessor,especially the microcontrollers, comprising at least a microprocessor 11and a memory ROM 16 and/or a non volatile memory 18 (for example EEPROM)comprising at least an application program to be executed, the unit 10comprising the hardware and software means designed to implement thecaller identification method described above and the smartcards in whichthese electronic units are fitted.

The invention therefore concerns a method for secured identification ofa calling module in a modular software architecture. The methodconsists, during an inter-module call, in saving information used toidentify the calling module in protected memory before branching theexecution to a precise point in the program of the called module and inusing the saved information to identify the calling module and check themodule chaining.

The method consists in triggering the execution of a routing 47 whichwrites in said protected memory said identification information andmanages alone or via a program interrupt management routine 48, known asan identification and program chaining check routing, the jump to theprogram of the called module.

In this particular embodiment, the whole checking method is carried outautomatically and secured by hardware means.

The save routine 47 triggers execution of the identification and programchaining check routine 48, specified in a stored predefined vector table46 indicating the address of the entry point of said routine 48.

The saved information used to identify the calling module consists inthe content of the program counter which indicates the address of thenext instruction in the program currently being executed in the callingmodule and in that the method consists in:

-   -   in case of centralised management, finding from said address by        comparison operations the identification of the calling module        using the address field of the calling module in the memory        space, via an identifier table;    -   in case of decentralised management, finding the identification        of the calling module by reading an identification attribute        attached to said address, the attribute showing the        identification of the calling module.

According to another form of realisation, the information saved used toidentify the calling module is an identifier of the calling modulestored in the status register 34 and updated before saving saididentification information as follows:

-   -   in case of centralised management, using the memory field of the        calling module, said field being defined by pages of the memory        space associated with an identifier specific to the module        considered, the identifiers of all system modules being stored        in an identifier table;    -   in case of decentralised management, from the attribute        associated with the page storing the inter-module call        instruction, the attribute showing the identification of the        module to which the memory page belongs.

When the identification information is saved, a consistency checkconsists in saving both the identification information of the calledmodule and of the calling module so that a module is characterised byinformation identifying it at the start and end of its execution and incomparing the identifiers of the module characterising the start and endof its execution.

A consistency check is carried out after identifying the calling modulebetween the identification obtained via the save of said identificationinformation and the identification obtained using software via anidentification variable.

Although specific embodiments of the invention have been described andillustrated, the invention is not to be limited to the specific forms orarrangements of parts so descried and illustrated. The invention islimited only by the claims.

1. Method to check module chaining in a modular software architecturelocated in an electronic unit (10) with microprocessor (11) comprising,apart from the microprocessor, a memory space (14, 16, 18), the methodcomprising: in response to execution of an inter-module call instructionbelonging to the instruction set of the microprocessor, triggeringexecution of a save routine in privilege mode allowing writing tootherwise read-only memory by the inter-module call instructionbelonging to the microprocessor's instruction set, from within theexecution of the save routine executing in privilege mode, beforebranching the execution of the calling module to a precise point in theprogram of the called module: automatically writing, with hardwaremeans, information used to identify the calling module in a memorylocation that is read-only to programs not executing in privilege modeand that is used to store calling program information, the writtencalling module identification information being hardware secured,identifying an identification and program chaining check routinespecific to the called module among several identification and programchaining routines; and using the identified identification and programchaining check routine, checking said written identification informationof the calling module.
 2. Method according to claim 1, comprising:managing the jump to the program of the called module, using said saveroutine (47) alone or via a program interrupt management routine (48),known as an identification and program chaining check routing routine.3. Method according to claim 1, wherein the checking is carried out andsecured with hardware means.
 4. Method according to claim 1, wherein thesaving comprises saving said identification information of the callingmodule in a protected memory, i.e., in one or more protected memoryfields accessible in read only mode, carrying out the writes only by aroutine (47) which saves said identification information while executingin a privilege mode that allows writing into said protected memoryfields.
 5. Method according to claim 1, wherein the saved informationused to identify the calling module consists in the content of at leastone of the following registers associated with the microprocessor (11):the program counter CO (30), the status register (34), the inter-modulecall triggering the storage of said identification information of thecalling module via the content of at least one of said registers.
 6. Anelectronic unit (10) with microprocessor with modular softwarearchitecture comprising at least a microprocessor (11), a memory space(14, 16, 18), comprising: means executing, in a privilege mode allowingwriting into memory that is otherwise read-only, during an inter-modulecall, before branching the execution to a precise point in the programof the called module: to automatically write with hardware means, into alocation for storing calling module information, information used toidentify the calling module in protected memory, written calling moduleidentification information being hardware secured, to identify anidentification and program chaining check routine specific to the calledmodule among several identification and program chaining routines; andto use the identified identification and program chaining check routine,checking said written identification information of the calling module.7. An integrated circuit card, comprising an electronic unit withmicroprocessor according to claim
 6. 8. A computer readable storagemedium comprising a computer program including program code instructionsto implement the method according to any of claim 1 through 5 when saidprogram is executed in a data processing system.